Socket management for always-on data connections

ABSTRACT

A method of automatically keeping sockets open for always-on applications in a GPRS context is provided. Information is maintained by each wireless device identifying each APN (access point name)-port pair associated with a PDP (packet data protocol) context used by an always-on application. Upon the PDP context becoming available after having become unavailable, a socket is registered for each port-APN pair associated with the PDP context.

RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 11/044,189 and claims the benefit thereof.

FIELD OF THE INVENTION

The invention relates to always-on data connections.

BACKGROUND OF THE INVENTION

A GPRS (general packet radio service) always-on wireless devicetypically has a single external connection and maintains a single PDP(packet data protocol) context. An always-on device does everything thatit can to keep its connection up all the time, at least while it isinstructed to do so. An example of a method of keeping a PDP context upall the time is taught in commonly assigned co-pending U.S. applicationSer. No. 10/987,658 entitled “Data-Capable Network Prioritization withReject Code Handling”. That application is hereby incorporated byreference in its entirety.

For an always-on device that only has a single PDP context and a singleapplication, maintaining the PDP context alone is sufficient to maintaindata connectivity for the always-on device. Thus, when the PDP contextfails, mechanisms such as those taught in the above-referenced patentapplication can be implemented to re-establish the PDP context andthereby re-establish the data connectivity with the single application.As abstract example of this is shown in FIG. 1 where there is shown aGPRS always-on device 10 having a single PDP context 12 that mapsone-to-one to the device and single application. As such, so long as thedevice is able to maintain the PDP context, data connectivity to thedevice is continuous.

Typically data applications are not always-on. For example, some e-mailapplications are only activated upon user command. Once activated, theapplication causes a PDP context to be created, opens a socket and mapsthe socket to the PDP context. The work concerning the e-mail iscompleted and then the PDP context and socket are closed. Similarbehaviour is implemented to open a socket when web browsing is conductedusing a wireless device. Typically, a timer is started after the lastuser action. When the timer expires (or the application is closed), thePDP context and socket are closed.

SUMMARY OF THE INVENTION

According to one broad aspect, the application provides a method in awireless device comprising: maintaining information identifying each APN(access point name)-port pair associated with a PDP (packet dataprotocol) context used by an always-on application; and upon the PDPcontext becoming available after having become unavailable, registeringa socket for each port-APN pair associated with the PDP context.

In some embodiments, the method comprises executing the maintaining andregistering for each of a plurality of PDP contexts each used by atleast one always-on application.

In some embodiments, the method further comprises: automaticallymaintaining the PDP context associated with an always-on application;detecting when the PDP context is no longer available; detecting whenthe PDP context is again available.

In some embodiments, the method further comprises: for each APN-portpair of an active context maintaining a respective socket identifier;upon the PDP context becoming unavailable, closing the socket having therespective socket identifier for each APN-port pair associated with thePDP context.

In some embodiments, the maintaining information comprises: whenregistering a new port for a given APN, adding an APN-port pair to alist of APN-port pairs; when de-registering a port for a given APN,removing the APN-port pair from the list.

In some embodiments, the method further comprises: when de-registeringan entire APN, closing a socket for each port-APN pair if the PDPcontext is available and removing each APN-port from the information.

In some embodiments, upon receipt of a request to register a new portfor a given APN, if the PDP context is available, applying registrationfor the APN-port pair.

In another embodiment, a computer readable medium having instructionsstored thereon for execution by a wireless device, the instructionscomprising an always-on application is adapted to implement one of themethods as summarized above.

In another embodiment, a wireless device is provided that is adapted toimplement one of the methods summarized above.

According to another broad aspect, the application provides a wirelessdevice comprising: a socket layer; an always-on application adapted toimplement one of the above summarized methods, wherein the registeringcomprises registering the socket with the socket layer.

According to another broad aspect, the application provides a wirelessdevice comprising: a socket layer; at least one always-on applicationadapted to implement one of the above summarized methods, wherein theregistering comprises registering the socket with the socket layer; atleast one intermittent application.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described withreference to the attached drawings in which:

FIG. 1 is a block diagram of a conventional GPRS always-on device;

FIG. 2 is a block diagram of a wireless device provided by an embodimentof the application;

FIG. 3 is a layer view of a wireless device provided by an embodiment ofthe application;

FIG. 4 is a layer view of another wireless device provided by anembodiment of the application;

FIG. 5 is a flowchart of a method of maintaining a list of APN-portpairs;

FIG. 6 is a flowchart of a method of re-establishing sockets after a PDPcontext becomes available;

FIG. 7 is a flowchart of a method of de-registering sockets after a PDPcontext becomes unavailable; and

FIG. 8 is a flowchart of a method of de-registering all of the portsassociated with a given APN.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A wireless device provided by an embodiment of the application will nowbe described with reference to FIG. 2. The wireless device, generallyindicated by 18, includes a socket layer 20 that supports a plurality ofPDP contexts including PDP context #1 26, . . . , PDP context #N 28.Each of these PDP contexts typically represents a separate logicalinterface. Also shown are one or more always-on applications 22. Atleast one of the always-on applications 22 includes an ASM (AutomaticSocket Manager) 23. Some implementations may feature additionalintermittent applications 24.

An APN (access point name) is a network identifier to which a connectionmay be established on a GPRS network. The set of information thatdescribes such a connection is called the PDP (packet data protocol)context.

It is to be understood that the wireless device 18 would also includethe remainder of the functionality necessary for such a device tooperate. Only the bare minimum functionality required to describe theembodiment has been shown. Typically the always-on applications 22 andintermittent applications 24 are implemented in software but hardwareimplementations are not to be ruled out. The socket layer 20 may beimplemented in software or hardware or a combination of hardware andsoftware.

An example of an always-on application 22 that might be implemented inwireless device 18 includes “push” email services. Examples ofintermittent applications include “pull” email and web browsing.

The socket layer 20 has a plurality of ports. Typically these includeTCP (transmission control protocol) ports and UDP (user datagramprotocol) ports. For example, web browsing uses a port on TCP. Publishedports having particular port numbers are often reserved for certainapplications. The socket layer 20 is typically managed by an operatingsystem of the device (not shown).

Each packet received by the wireless device 18 is received with a headerthat indicates a port number, this being a logical port on the device.The socket layer 20 takes data from the physical connection(s), and usesthe port number to determine where the packet needs to go. Applications(both the always-on applications and intermittent applications) registerwith the socket layer to request a socket. The socket layer then binds asocket to a particular protocol/port combination. For example, TCP port80 is typically used for web traffic. Once this binding has taken place,the application is able to communicate using the physical interfaces.

In some implementations, an application may use multiple PDP contexts,and/or multiple applications may use the same PDP context. In the lattercase the device operating system ensures only one application is allowedto bind to any given port/protocol combination.

When one of the PDP contexts 26, 28 fails, all of the associated socketsbecome invalid. From that point on, the application that used the PDPcontext cannot receive anything and cannot send anything using thesocket. After recovery of the PDP context, for example using the methoddescribed in the above-referenced co-pending application, the always-onapplication 22 still will not be able to communicate until it createsnew sockets. It is noted that for the intermittent application 24, thefact that the PDP context goes down is less relevant since it isdesigned to deal intermittently with the PDP context. However, if thePDP context does go down while the intermittent application 24 isactive, then it too will need to re-establish its sockets before it cancontinue communicating these in the physical interfaces. However, forsuch applications typically it will be up to the user to re-initiate theintermittent application. This will result in a new PDP context and newsockets being created.

An embodiment of the application provides an automated method for thealways-on application 22 to re-establish the sockets after the PDPcontext has been re-established. The particular functionality forachieving this is summarised as the automatic socket manager 23 in FIG.2. This is preferably implemented in software as part of the always-onapplication but other implementations are also contemplated.

Referring now to FIG. 3, shown is a different view of a wireless devicewithin which the automatic socket manager can be implemented. The devicehas a device operating system 50 and a device independent always-onapplication 54. Between these is an integration layer 52 that allows thedevice independent always-on application 54 to communicate with thedevice OS (operating system) 50. The integration layer 52 contains anautomatic socket manager 56. It is noted that the socket API is betweenthe device operating system 50 and the integration layer 52. Theautomatic socket manager 56 maintains a list of APN (access pointname)/PDP contexts 58 relevant to the particular application, and foreach such APN/PDP context maintains a respective list of ports 60. Theillustrated example also includes a status 62 for each APN/PDP contextindicating whether or not the APN/PDP context is available. In oneexample, the availability is indicated by maintaining the PDP state ofthe PDP context. In the details below, PDP state is used to indicatedthe availability/unavailability of the PDP context. However, the ASM mayalternatively maintain its own information on this. For example, asingle binary flag can be used to indicate availability/unavailability.When an APN is first registered, the PDP state is “INIT”. When the PDPcontext activates, the PDP state is set to “ACTIVE”. When the PDPcontext deactivates, the PDP state is set to “INACTIVE”. Also it ispossible for the activation to fail in which case the PDP state is“REJECTED”. The combination of an APN/PDP and a port in the list ofports 62 will be referred to as an APN-port pair. Also shown for eachAPN-port pair of an active PDP context is a socket identifier 61. Thesesocket identifiers are needed when it is time to apply de-registrations.There are no sockets for an inactive PDP context.

While the example of FIG. 3 shows a very specific way of storingAPN-port pair information, it is to be understood that other structures(any appropriate information store) and methods of maintaining thisinformation may alternatively be employed.

Examples of methods by which the automatic socket manager 56 or the ASM23 of FIG. 2 uses such data to perform automatic socket management willbe described below in detail with respect to FIGS. 5 through 8.

For the embodiment of FIG. 3, it is the device independence of always-onapplication 54 that necessitates an integration layer, and the ASM 56has been included in the integration layer 52 in the particular example.

FIG. 4 shows another wireless device in which there is a deviceoperating system 70 upon which is running an always-on application 72containing an automatic socket manager 74. The layered breakdowns ofFIGS. 3 and 4 provide two specific examples of locations where the ASMmight be implemented. More generally, an ASM can be implemented in anyappropriate place within the wireless device that allows it to managesockets on behalf of an always-on application.

Referring now to FIG. 5, shown is a first method that may be implementedby an automatic socket manager to maintain a list of registered port-APNpairs. The method begins at step 5-1 with the occurrence of aRadioRegisterUdpPort action. RadioRegisterUdpPort is an action taken bythe application. The command is a parameter provided by the application.The command may be a register command or a de-register command. Furtherparameters include a port number and an APN. Note that there is aone-to-one mapping between APNs and PDP contexts. In the event thecommand is a register command (yes path, step 5-2) then at step 5-3 acheck is made to see if the port-APN pair has already been registered.If so (yes path, step 5-3) the method ends for that particular command.Otherwise, if the port-APN pair is not already registered (no path, step5-3) then the port-APN pair is added to the list of registered port-APNpairs at step 5-4. If the PDP state is active at that time (yes path,step 5-5) then the registration is applied at step 5-8. If the PDP stateis not active (no path, step 5-5) then the registration is not applied,but it has still been added to the list of registered port-APN pairs.

If the command was not a register command (no path, step 5-2) then it isa de-register command, and a check is made at step 5-6 to see if theport-APN pair is in the registered list. If it is not in the list (nopath, step 5-6) then nothing further needs to be done. On the otherhand, if it is in the list (yes path, step 5-6) then the port-APN pairis removed from the list at step 5-7 and in the event the PDP state isactive (yes path, step 5-9) the de-registration is applied at step 5-10.The socket identifier is also stored in association with the port-APNpair.

The first step in the flow chart of FIG. 5 amounts to a declaration ofinterest for a particular port and a particular APN for UDP. This mightoccur when the device is initially turned on, or at some later time whenthe application decides that it is interested in receiving data. Apre-condition to this is that the PDP context and APN have becomeassociated. This can be achieved, for example, with a radio register APNcommand, resulting in the creation of a PDP context associated to thatAPN, if one does not already exist.

It can be seen that the flow chart of FIG. 5 accommodates the processingof requests for new ports and for the removal of existing ports. Thelist of port-APN pairs that is maintained survives PDP context failuresand survives the subsequent invalidation of all the sockets associatedwith the PDP contexts. As such, this information can be used tore-establish the sockets after the failure of a particular PDP context.

The steps executed to re-establish the sockets after the failure of thePDP context are indicated in the flow chart of FIG. 6. The method beginswith the receipt of a message indicating that the PDP context isavailable again at step 6-1 or otherwise becoming aware that the PDPcontext is available. Then, at step 6-2 for each registered port-APNpair associated with the PDP context, the registration is applied to setup a new socket for that port-APN pair. The socket identifier is storedin association with the port-APN pair. At the end of the method of FIG.6, all of the sockets will have been re-established. It is noted that inthe event a request for an additional socket had been received duringthe period that the PDP context was down, a registration for that isalso applied.

Referring now to FIG. 7, shown is a flow chart of method steps executedwhen the PDP context becomes unavailable. The method begins at step 7-2with the receipt of a message or other indication that the PDP contexthas become unavailable. At step 7-2, for each of the port-APN pairs inthe list for that particular PDP context, a de-registration is appliedto the socket having the associated socket identifier. Thus, at the endof the method of FIG. 7, de-registrations have been applied for each ofthe port-APN pairs associated with the PDP context that has becomeunavailable. Applying the de-registrations means closing the sockets.

Referring now to FIG. 8, shown is a flow chart of method steps executedby the automatic socket manager when it is time to de-register all ofthe ports associated with a given APN. This might occur, for example, ifthe user has made a configuration change to the application, or if theapplication is about to close. The method begins with the receipt of amessage or other indication that it is time to de-register a given APNat step 8-1. This is followed by steps 8-2 and 8-3 that are executed foreach port on that APN. At step 8-2 the port-APN pair is removed from thelist and at step 8-3 the de-registration is applied to the associatedsocket if the PDP state is ACTIVE. Thus, at the end of the method ofFIG. 8 all of the ports for the selected APN will have beende-registered, and the list maintained by the automatic socket managerwill be empty for that particular APN.

The embodiments described have been particular to GPRS applicationsemploying PDP context and APNs. It is to be understood that standardsevolve, details on the GPRS standard and evolutions thereof can be foundat www.3gpp.com. Embodiments apply to the current standard, paststandard, and future evolutions of the standard.

More generally, in another embodiment, an always-on application makesuse of a set of one or more sockets in association with a data service,and is responsible for setting up new sockets when the data servicefails and is then re-established. The specific embodiments described usethe APN/PDP context mechanism to identify data services but it is to beunderstood other mechanisms may alternatively be employed both for GPRSapplications and non-GPRS applications. The methods employed in suchembodiments may be very similar to those described for the GPRS case. AnASM maintains an identification of the sockets used by the always-onapplication that are associated with a particular data service. When thedata service fails, the sockets are de-registered; when the data serviceis re-established, new sockets are established for the always-onapplication to communicate via the data service.

Numerous modifications and variations of the present invention arepossible in light of the above teachings. It is therefore to beunderstood that within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described herein.

1. A method in a wireless device comprising: maintaining informationidentifying each APN (access point name)-port pair associated with a PDP(packet data protocol) context used by an always-on application; andupon the PDP context becoming available after having become unavailable,registering a socket for each APN-port pair associated with the PDPcontext.
 2. The method of claim 1 comprising executing the maintainingand registering for each of a plurality of PDP contexts each used by atleast one always-on application.
 3. The method of claim 1 furthercomprising: automatically maintaining the PDP context associated with analways-on application; detecting when the PDP context is no longeravailable; and detecting when the PDP context is again available.
 4. Themethod of claim 1 further comprising: for each APN-port pair of anactive context maintaining a respective socket identifier; and upon thePDP context becoming unavailable, closing the socket having therespective socket identifier for each APN-port pair associated with thePDP context.
 5. The method of claim 1 wherein the maintaininginformation comprises: when registering a new port for a given APN,adding an APN-port pair to a list of APN-port pairs; and whende-registering a port for a given APN, removing the APN-port pair fromthe list.
 6. The method of claim 1 further comprising: whende-registering an entire APN, closing the socket for each APN-port pairif the PDP context is available and removing each APN-port pairs fromthe information.
 7. The method of claim 5 wherein upon receipt of arequest to register the new port for the given APN, if the PDP contextis available, applying registration for the APN-port pair.
 8. A computerreadable medium having instructions stored thereon for execution by awireless device, the instructions comprising an always-on applicationconfigured to: maintain information identifying each APN (access pointname)-port pair associated with a PDP (packet data protocol) contextused by an always-on application; and upon the PDP context becomingavailable after having become unavailable, register a socket for eachAPN-port pair associated with the PDP context.
 9. A wireless devicecomprising: a socket layer; an always on application; an automaticsocket manager; the automatic socket manager being configured tomaintain in an information store information identifying each APN(access point name)-port pair associated with a PDP (packet dataprotocol) context used by the always-on application; and wherein uponthe PDP context becoming available after having become unavailable, theautomatic socket manager registers a socket with said socket layer foreach APN-port pair associated with the PDP context.
 10. The wirelessdevice of claim 9 wherein: the information store is used to maintaininformation identifying each APN (access point name)-port pairassociated with each of a plurality of PDP (packet data protocol)contexts used by the always-on application; and upon one of the PDPcontexts becoming available after having become unavailable, theautomatic socket manager registers a socket for each APN-port pairassociated with the PDP context that became unavailable.
 11. Thewireless device of claim 9 wherein the automatic socket manager isfurther configured to: for each APN-port pair of an active context,maintain a respective socket identifier; and upon the PDP contextbecoming unavailable, close the socket having the respective socketidentifier for each APN-port pair associated with the PDP context. 12.The wireless device of claim 9 wherein the information is maintained by:when registering a new port for a given APN, adding an APN-port pair toa list of APN-port pairs; and when de-registering a port for a givenAPN, removing the APN-port pair from the list.
 13. The wireless deviceof claim 9, wherein the automatic socket manager is further configuredto: when de-registering an entire APN, closing a socket for eachAPN-port pair if the PDP context is available and removing each APN-portpair from the information.
 14. A wireless device comprising: a socketlayer; an always-on application configured to: maintain informationidentifying each APN (access point name)-port pair associated with a PDP(packet data protocol) context used by an always-on application; andupon the PDP context becoming available after having become unavailable,register a socket for each APN-port pair associated with the PDPcontext, wherein register a socket comprises register the socket withthe socket layer.
 15. The wireless device of claim 14 furthercomprising: at least one intermittent application.
 16. A method in awireless device comprising: for each of at least one data service usedby an always-on application, maintaining information identifying eachsocket used by the always-on application in using the data service; andupon one of the data services becoming available after having becomeunavailable, registering a new socket for each socket used by thealways-on application, in using the data service.
 17. A computerreadable medium having instructions stored thereon for execution by awireless device, the instructions comprising an always-on applicationconfigured to: for each of at least one data service used by analways-on application, maintain information identifying each socket usedby the always-on application in using the data service; and upon one ofthe data services becoming available after having become unavailable,register a new socket for each socket used by the always-on application,in using the data service.
 18. A wireless device configured to: for eachof at least one data service used by an always-on application, maintaininformation identifying each socket used by the always-on application inusing the data service; and upon one of the data services becomingavailable after having become unavailable, register a new socket foreach socket used by the always-on application, in using the dataservice.